5章 コメントすべきことを知る
コメントの目的とは、コードの意図を読み手に理解してもらうことである。 (5.5)
意図＝コードの書き手の頭の中にある情報
頭の中にある情報をコメントするのであって、コードを見ればわかることをコメントすべきではない
コメントに価値をもたせる (5.1)
「優れたコード > ひどいコード + 優れたコメント」(5.1)
この章としては、コメントすべきことは書くという立場に見える
WHATでもWHYでもHOWでも理解に役立つものは何でもいいから書こう (5.3)
（コードには How、テストコードには What、コミットログには Why、コードコメントには Why notを書こうとも一致しない）
要約コメント (5.3)
関数に分割できるならそうしよう。
（分割すべきと考える。ref: 関数の抽出）
（複数のことを言っているから伝えたいことがぼやけている？）
5.1 コメントするべきでは「ない」こと
コードからすぐにわかること
ひどい名前へのコメント
（コメント（Code Smell）の話）
コードで自己文書化
（コード自体が文書化というような意味と理解）
5.2 自分の考えを記録する
コードを書いているときの考えをコメンタリーに残す
コードの欠陥へのコメント
TODO / FIXME / HACK / XXX
大切なのは、これからコードをどうしたいかを自由にコメントに書くことだ
（第4章 コメント（Clean Code）のTODOコメント）
定数にコメントをつける
定数の値を決めたときに頭のなかで考えていたことを記録する
5.3 読み手の立場になって考える
プロジェクトを熟知していない人の立場になるということ
質問が来そうな箇所
驚きそうな箇所
「全体像」をコメントする
新しいメンバは全体像の理解が難しい
ファイルやクラスにコメント
5.4 ライターズブロックを乗り越える
まず書き出す（＝脳内ダンプ）→改善
感想：TDD（動作するコード→動作するきれいなコード）のよう